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Facilitator  Guide 


Acquisition  Reform  Week  III 
Open  Systems  Concepts  &  Application  to  DoD  Weapon 

Systems 


Scope  of  Seminar 

This  seminar  addresses  the  Open  Systems  Approach  (OSA)  to  weapons  system 
design,  one  of  the  centerpieces  of  DoD  acquisition  reform.  The  seminar  focuses  on  the 
OSA  as  an  integrated  technical  and  business  strategy  that  defines  key  interfaces  for  a 
weapon  system  and  facilitates  the  use  of  standards  widely  supported  and  used  by 
commercial  Industry.  It  is  an  innovative  way  of  doing  business,  which  allows  program 
managers  the  flexibility  to  leverage  the  creativity  and  competitive  pressures  of  the 
commercial  marketplace  to  find  less  costly  solutions  for  weapon  systems.  One  of  the 
objectives  of  the  seminar  is  to  highlight  new  techniques  for  designing  weapons  systems 
using  an  Open  Systems  Approach.  A  short  exercise  has  been  included  in  the  seminar 
where  participants  will  select  a  standard  interface  for  a  system  using  the  concepts  and 
techniques  taught  in  the  seminar.  * 

Instructions  to  Facilitators 

Each  Acquisition  Reform  Week  III  seminar  takes  approximately  one  and  one-half  hours 
to  complete.  To  maximize  the  potential  for  participants  to  gain  an  overall  understanding 
of  the  subject,  we  suggest  you  hand  out  presentation  materials  2-to-24  hours  in 
advance.  If  participants  read  the  information  before  the  seminar,  the  facilitator  can 
conduct  a  brief  recap  and  then  devote  a  significant  portion  of  the  time  to  practical 
experience  such  as  exercises,  e.g.  working  through  the  scenario  which  demonstrates 
the  principles  outlined  in  the  presentation. 

As  Facilitator  you  will  need  a  copy  of  the  full  package  which  is  detailed  below. 
Participants  should  receive  item  #2  in  advance,  if  possible:  item  #3  should  be  handed 
out  in  the  seminar.  Items  #1  and  #4  are  for  the  exclusive  use  of  the  Facilitator. 


Included  in  this  file  are  the  following: 

1.  Facilitator  Guide . 1-2 

2.  Overview  and  Presentation  for  Participants . 3-26 

3.  Exercise  Task . 27-28 

4.  Solution . 29 


TIP:  Print  pages  in  the  order  noted  so  you  will  have  one  complete  package.  Then, 
duplicate  individual  sections  as  needed  depending  on  number  of  participants.  This  will 
ensure  materials  are  in  correct  order  and  will  reduce  the  risk  of  the  file  being  too  large 
for  computer  or  printer  equipment  to  handle  with  ease. 
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Main  Teaching  Points 

These  are  the  four  main  teaching  points  in  this  seminar.  Before  proceeding  to  the 
practice  session,  make  sure  participants  understand  the  following: 


1 .  The  basic  terms  and  concepts  of  Open  Systems. 

2.  The  potential  benefits  and  challenges  of  using  Open  Systems. 

3.  The  practical  skills  associated  with  an  Open  System  Approach  in  the  DoD 
acquisition  process. 

4.  How  program  life-cycle  economics  can  benefit  from  the  implementation  of  Open 
Systems. 


*This  seminar  was  tailored  from  materials  used  in  the  2  y2  day  Open  Systems  Concepts 
and  Application  to  DoD  Weapon  Systems  Workshop,  developed  and  presented  by  the 
BRTRC  Institute  for  Open  Systems  Joint  Task  Force.  For  more  information  please 
contact  (703)  205-1593,  or  visit  our  website  at:  http://institute.brtrc.com. 
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Overview  and  Presentation  for  Participants 


Acquisition  Reform  Week  III 
Open  Systems  Concepts  &  Application  to  DoD  Weapon 

Systems 


Overview 

Welcome  to  the  Acquisition  Reform  Week  III  seminar,  Open  Systems  Concepts  and 
Application  to  DoD  Weapon  Systems.  This  session  is  designed  to  help  participants  do 
the  following: 

1 .  Understand  basic  terms  and  concepts  of  Open  Systems. 

2.  Be  able  to  describe  and  discuss  potential  benefits  and  challenges  of  using  Open 
Systems. 

3.  Refine  practical  skills  using  an  Open  Systems  Approach  in  the  DoD  acquisition 
process. 

4.  Know  how  program  life-cycle  economics  can  benefit  from  the  implementation  of 
Open  Systems. 

Exercise  Objective 

The  focus  of  this  exercise  is  to  apply  interface  standards  selection  criteria,  perform  risk 
assessment,  and  use  technical  and  business  considerations  to  develop  a  portion  of  a 
system  architecture.  Participants  will  work  in  small  groups  to  analyze,  rank,  select  and 
justify  interfaces  appropriate  for  system  requirements,  timeliness  and  cost. 

This  exercise  reinforces  material  in  Open  Systems  Approach.  It  emphasizes  the 
importance  of  selecting  appropriate  interface  standards  and  illustrates  risk 
management  aspects  inherent  in  good  Open  Systems  design. 

This  block  allows  participants  to  examine  a  number  of  different  interfaces  that  meet 
requirements  of  specific  and  innovative  technology.  Satisfactory  completion  of  this 
training  material  requires  a  complete  understanding  of  the  major  issues  pertaining  to 
Open  Systems  Approach  as  presented  in  the  seminar. 

instructions  to  Participants 

Please  review  the  presentation.  Be  prepared  to  ask  questions  and/or  participate  in  a 
brief  recap.  This  will  be  followed  by  a  practice  session  which  will  test  your 
understanding  of  the  principles  captured  in  the  presentation  material  and  give  you 
hands-on  experience  in  dealing  with  applying  best  Open  Systems  Approach 
techniques. 
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Open  Systems-Concepts and  Application  to 
DoD  Weapon  Systems  Seminar 


Open  Systems  Concepts 
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The  Open  Systems  Approach  (OSA)  is  an  integrated  technical  and  business  strategy 
that  defines  key  interfaces  for  a  system  or  piece  of  equipment  that  is  being  developed. 

OSA  is  a  new  way  of  doing  business  for  DoD,  and  an  important  part  of  Acquisition 
Reform.  Hard  pressed  to  maintain  the  superiority  of  U.S.  military  systems  within  severe 
budget  constraints,  DoD  program  managers  need  the  flexibility  of  open  systems  to 
leverage  the  creativity  and  competitive  pressures  of  the  commercial  marketplace. 

During  this  seminar  we  will  discuss  the  basics  of  the  OSA. 
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BENEFITS/CHALLENGES 


-  Rapid  Prototyping 

-  Lower  Costs  i 

>  Work  Avoidance/Reuse 

>  Economy  of  Scaie 

>  Competition 
.  Reduced  Cycle  Time 

-  Better  Tested  Products 

-  c^pamless  Evolution 

Benefits 


-Trading  Requirements  Aga 

1  FxistinQ  Standards 
'  Fuily  Defining 

^^XringProdu^^^ 

Challenges 


RISK  MITIGATION 


STANDARDS 

COMPLIANCE 
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This  slide  illustrates  what  we’re  going  to  concentrate  on  during  this  seminar--the 
benefits  and  challenges  of  applying  an  OSA.  After  we  have  discussed  the  lecture 
slides,  we  have  a  brief  exercise  to  illustrate  the  basics  of  selecting  an  Open  System  for 
a  weapon  system. 

Weapon  systems  present  unique  challenges  to  implementing  an  OSA.  Perhaps  the 
greatest  challenge  lies  in  applying  the  concept  to  legacy  systems  where  “closed  or 
proprietary”  designs  and  inflexible  infrastructures  make  it  difficult  to  integrate  new 
components.  Also,  the  harsh  environment  in  which  our  weapon  systems  operate  may 
make  it  difficult  to  use  commercial  components. 

The  open  systems  approach  is  neither  a  panacea  nor  risk  free.  The  types  of  risks 
experienced  by  the  program  are  different  than  those  experienced  by  traditional 
acquisition  approaches  because  our  control  over  the  system  development  has 
changed.  The  open  systems  approach  is  a  combined  business  and  engineering 
strategy  where  engineering  decisions  are  driven  by  business  considerations.  The 
program  leadership  must  weigh  the  potential  benefits  against  the  risks  in  making  the 
“buy  versus  build”  decision. 
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WHY  USE  OPEN  SYSTEMS?  cq.WSitijBa 

 -WEEK 


30  YEAR  SERVICE  LIFE 


TIME  TO  DESIGN,  BUILD,  TEST 


DOD  PROCESS  GROWTH 


LEGACY  SYSTEMS 
ARE  HARD  TO 
UPGRADE 


DECLINING 

BUDGETS 


DEVELOPMENT 
CYCLE  TIMES 


Open  Systems  rely  upon 
widely  available,  timely 
and  economical  solutions 
for  some  systems  that 
now... 

-  Cost  too  much  to  develop 

-  Cost  too  much  to  support 

-  Cost  too  much  to  modify 

-  Can’t  readily  use  new  technology 

-  Don’t  inter-operate  well 
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Weapon  systems  expense  reflects  in  part  their  ‘closed’  designs  that  are  based  on  non¬ 
standard  interfaces  which  are  typically  supported  by  only  a  few  suppliers.  Having  only  a 
few  suppliers  limits  competition  and  tends  to  increase  costs  and  the  possibility  of 
obsolescence. 

An  OSA,  on  the  other  hand,  bases  the  weapons  system’s  design  on  open,  commercially 
supported  interface  standards  with  the  prospects  of  a  large  supplier  and  customer 
base. 

Legacy  Systems  Are  Hard  to  Upgrade: 

...OSA  facilitates  technology  insertion 
Declining  Budgets: 

...OSA  can  reduce  cost  through  competition  via  many  suppliers 
Development  Cycle: 

...OSA  can  shorten  the  development  cycle 
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SYSTEM  DEVELOPMENT  CYCLES 


»i 


DESIGN  DEVELOP  ' 


Commercial 
market  has 
new  technology 
4  to  8  times  faster 


Supporting 
Technoiogy  is 
Constantiy  Evoiving 


Technology  Cycle  Times 
Electronics  - 18  months 
Avionics  -  6  years 
Aircraft  Engines  -14  years 
Airframes  -  25  years 

Open  Systems  reduce  the  probabiiity  of  fieiding  obsoiete  equipment,  or  having 
to  redesign  your  system  for  upgrades  and  modifications  in  the  future 


Open  Systems  Concepts 


•  OS  allows  products  to  fit  inside  and  update  functions  as  time  goes  on. 

•  Open  systems  are  important  because  it  helps  cut  cycle  times  and  facilitates 
technology  infusion.  DoD  weapons  systems  development  time  ranges  from  8  to  15 
years.  By  contrast,  the  average  commercial  sector  brings  new  products  to  market  in 
about  half  that  time.  In  the  area  of  electronics,  the  commercial  market  develops 
new  technology  four  to  eight  times  faster  than  the  normal  weapons  system 
development  cycle.  DoD  cannot  afford  to  be  3  or  4  generations  behind  the 
commercial  market. 

•  When  cycle  time  grows  beyond  a  certain  point,  the  fact  that  technology  changes 
over  time  becomes  a  significant  factor.  Beyond  a  certain  cycle  time,  we  end  up 
fielding  systems  with  obsolete  technology  on  the  very  first  item  off  the  production 
line. 

•  The  military  also  needs  the  ability  to  integrate  new  technology  into  legacy  weapons 
systems.  OSA  provides  this  capability. 

•  We  maintain  systems  for  20  to  40  years.  Open  systems  allows  us  to  upgrade  these 
systems  at  relatively  low  cost.  The  result  is  a  superior  system  over  the  total  life 
cycle  at  a  lower  cost  to  the  government 
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Longer  system  life  times  aggravate  an  already  apparent  problem  in  the  long  term 
affordability  of  weapon  systems,  as  indicated  in  the  O&S  phase  shown  in  the  above 
figure.  In  total,  28%  of  life  cycle  costs  are  incurred  prior  to  IOC,  whereas  72%  of  the  life 
cycle  cost  is  incurred  during  the  service  lifetime  [from  6/12/96  briefing  by  Principal 
Assistant  Deputy  Under  Secretary  of  Defense  for  Logistics,  Mr.  Roy  Willis]. 

We  typically  concentrate  on  the  short  term  when  we  deal  with  a  product.  We 
concentrate  on  having  the  lowest  development  costs  possible.  Referring  to  the  above 
figure,  it  is  clear  we  should  concentrate  on  doing  things  in  development  that  will 
decrease  costs  during  production  and  especially  during  O&S. 

An  open  systems  approach  focuses  on  system  life  cycle  supportability  by  considering 
life  cycle  support  requirements  up  front,  permitting  system  evolution  with  technology 
development,  anticipating  technology  obsolescence  in  system  design  and  by 
supporting  technology  insertion. 

As  DoD  limits  the  number  of  new  weapon  systems  procurements,  it  is  also  extending 
the  life  of  the  systems  currently  fielded  some  up  to.  A  30-50  year  service  lifetime. 
Examples  include  the  UH-1  Helicopter,  B-52  Bomber,  Hawk  Missile,  AIM-9  Missile,  C- 
130  Aircraft,  M-113  Armored  Personnel  Carrier,  SSN  688  Submarine.  An  open  systems 
approach  specifically  addresses  issues  of  affordability  and  supportability  associated 
with  long  system  life  times. 
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EXPLOITING  THE 
DEVELOPMENT  CYCLE 


^EEKI 
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•  The  shift  from  DoD  directed-development  to  applications  developed  for  and  by 
industry  requires  a  major  re-orientation  of  our  thinking  about  requirements,  not  only 
in  the  electronics  arena  but  throughout  our  approach  to  performance  specifications 
to  meet  military  needs  for  technology  infusion. 

•  One  example  of  how  industry  provided  a  solution  when  an  open  standard  was 
available: 

-  At  the  time  of  Desert  Storm,  a  MILSPEC  GPS  receiver  cost  $34,000  each 
and  weighed  17  pounds.  The  procurement  lead  time  was  18  months.  The 
Army  purchased  commercial  GPS  receivers  weighing  3  pounds  that  cost 
$1,300. 
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Another  reason  that  open  systems  have  become  a  priority  is  that  the  market  place  has 
changed.  In  the  1950’s,  DoD  was  the  dominant  force  in  the  market  place.  DoD 
requirements  drove  development  of  new  products  and  new  technology.  In  the  1990’s, 
the  opposite  is  true;  commercial  demand  drives  product  and  technology  development. 

DoD  can  take  advantage  of  commercial  innovation,  research  and  development  to  drive 
down  the  cost  of  developing,  acquiring  and  maintaining  weapons  systems.  Rather  than 
relying  on  unique,  expensive  programs,  DoD  can  leverage  the  commercial  investment 
to  make  the  most  of  available  and  shrinking  defense  funds. 

The  open  systems  approach  achieves  this  effect  by  designing  systems  to  use  open, 
widely  supported  standards  and  interfaces  (e.g.,  commercial).  The  cost  benefits 
accrued  depend  on  how  widespread  the  standard  is  supported  in  the  market,  and  how 
widely  the  standard  is  used  within  a  weapon  systems  domain  (e.g.,  avionics,  ground 
vehicles,  missiles,  soldier  systems  and  marine). 
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DOD^sOPEN  SYSTEMSVISION 


To  establish  in  DoD  an  open  systems 
approach  as  the  foundation  for  all 
weapon  systems  acquisitions  in  order 
to  lower  life  cycle  costs  and  improve 
weapons  systems  performance. 


Open  Systems  Joint  Task  Force 
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Some  of  the  keys  to  achieving  DoD’s  vision  include: 

-  Assure  the  DoD  acquisition  workforce  understand  open  systems  and  know  how  to 
implement  it 

-  Assure  industry  and  standards  bodies  are  aware  of  the  policy  and  new  opportunities 

-  Identify  opportunities  for  open  systems  architectures 

-  Share  lessons  learned 

-  Establish  key  interface  standards  for  use  in  weapon  systems 

-  Integrate  open  systems  with  other  DoD  policies  and  initiatives 

-  Establish  the  open  systems  in  continuing  practice  across  the  DoD 
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How  does  Open  Systems  relate  to  other  acquisition  reform  initiatives? 

The  open  systems  approach  is  an  “ENABLER”.  It: 

•  Enables  Cost  as  an  Independent  Variable  (CAIV)  by  emphasizing  the  importance  of 
selecting  interface  standards  which  support  affordable  systems  evolution. 

•  Supports  commercial  items  and  NDI  initiatives  by  using  standards-based  interfaces 
supported  by  these  products. 

•  Supports  Modernization  Through  Spares,  Horizontal  Technology  Insertion  and 
Evolutionary  Acquisition  by  promoting  the  use  of  standards-based  interfaces  based 
on  widely  supported  standards  and  focusing  DoD’s  engineering  and  management  of 
weapons  systems  “at  the  interface.” 

•  Enables  Horizontal  Technology  Insertion  by  promoting  the  use  of  standards-based 
interfaces  across  weapons  systems  domain  and  their  product  lines. 

Finally,  open  system  interfaces  specifications  are,  in  fact.  Performance  Specifications 

at  the  interface  and  their  use  is  consistent  with  the  Performance  Specifications 

initiative. 
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OPEN  SYSTEMS  HAVE 
MEASURABLE  BENEFITS 


Army  Intelligence  and  Electronic  Warfare  Common 
Sensor  (lEWCS) 

•  Cost  of  moving  to  an 
Open  System  Architecture: 

-  18  month  delay  and  $10M 

•  Superior  Performance 

-  Technical 

-  Operational 

•  Acceierated  Scheduie 

-  R&D:  64%  (even  with  18  month  slip) 

-  EMD:  29%  reduction 

•  Cost  Avoidance 

-  R&D  and  Production:  $567  M 

-  O&S  (projected):  $435  M 

-  Marine  Corps  $149-481  M 


Open  Systems  Concepts 


11 


An  OSA  success  story.  The  cost  of  moving  to  an  OSA  was  18  month  program  delay 

and$10M.  A  few  key  results  were: 

•  Better  performance:  increased  frequency  range  and  speed/precision. 

•  Each  configuration  can  perform  all  of  the  missions. 

•  All  configurations  use  commonly  fielded  vehicles,  saving  O&S  costs.  Compared  to 
its  predecessor,  it  requires  46  percent  fewer  operators,  65  percent  fewer  vehicles, 
and  60  percent  less  airlift 

•  Reduced  research  and  development  time  by  64  percent,  despite  the  18  months  slip 
to  initiate  the  OSA 

•  Reduced  engineering  and  manufacturing  development  time  by  approximately  29 
percent  R&D.  Given  an  estimated  total  R&D  and  production  costs  of  approximately 
$845  million,  the  estimated  cost  avoidance  for  these  two  life-cycle  phases  alone  is 
approximately  $567  million. 

•  O&S.  When  combined  with  an  estimated  cost  avoidance  for  the  O&S  phase  of 
approximately  $436  million,  the  OSA-based  lEWCS  acquisition  represents  a  cost 
avoidance  to  the  Army  of  over  $1  billion. 
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POSSIBLE  RISKS 

WEEK 


Government  becomes  a  consumer  instead  of 
the  designer  -  iess  controi  over  outcomes 
Open  Systems  may  not  provide  the  optimum 
design  for  moduies,  components,  subsystems 
and  short-term  soiutions 
Building  Open  Systems  takes  time  for 

-  Market  analysis 

-  Prototyping 

-  Standards  Seiection 

The  standards  selection  process  has  risks 
Open  Interface  extensions  may  cause  problems 
later  in  the  life  cycle 

Open  Systems  may  or  may  not  be  appropriate 
for  legacy  systems 
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There  are  risks  to  nnanage  with  an  OSA.  They  result  primarily  from  our  loss  of  control 
over  the  detailed  design  of  the  system. 

With  an  OSA,  our  vantage  point  is  now  the  “interface”  to  the  component  as  opposed  to 
having  detailed  knowledge  and  control  over  design.  Without  this  level  of  control  there 
are  a  number  of  “performance  risks”  considerations:  can  standards-based  components 
survive  the  environment?  Are  they  reliable?  Can  they  satisfy  special  performance 
requirements  such  as  fault  tolerance,  security,  real  time,  is  there  BIT? 

One  key  risk  is  picking  the  correct  standard.  An  ongoing  DoD  effort  has  workgroups 
examining  existing  commercial  standards  and  working  to  select  appropriate  ones  to 
use.  In  some  cases,  such  as  the  Information  Technology  area,  this  work  is  nearing 
completion,  and  mandatory  standards  are  being  published  within  DoD. 

Being  part  of  a  larger  market  we  may  have  little  influence  over  the  vendor.  Frequent 
configuration  changes  with  little  or  no  warning,  could  add  unreasonable  burden  to 
configuration  management  efforts.  Obsolescence  risk  can  be  minimized  by  ensuring 
that  selected  interface  standards  have  wide  market  support  and  that  there  is  a  strategy 
for  interface  upgrade. 


3/17/98 


Open  Systems  Concepts 


14 


DEFINITIONS 


^cq.yj#iji;pn 

-V\  EI:K 


A  system  - 
is  a  collection  of 
interacting... 

...subsystems  - 
which  are  coliections 
of  interacting... 

...components  - 
either  hardware, 
software,  or  human, ... 


...that  are  connected  by  interfaces  - 

to  support  the  interchange  of  information,  activity,  or  materiai 
essentiai  to  the  functioning  of  the  system. 
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It  is  important  to  understand  the  terms  used  in  Open  Systems.  Unfortunately,  many  of 
the  terms  that  we  will  use  have  numerous  definitions  and  usage.  Therefore,  we  wiii 
spend  some  time  initiaily  discussing  the  definition  of  terms  we  wili  use  to  aid  in  our 
mutuai  understanding. 

For  the  purpose  of  this  discussion,  systems  are  comprised  of  subsystems  which  are,  in 
turn,  comprised  of  components  where  each  is  separated  by  weli  defined  interfaces. 

An  interface  is  the  shared  boundary  or  connection  between  two  or  more  components. 
Interfaces  support  the  interchange  of  information,  activity  or  material  essential  to  the 
functioning  of  the  system.  Interfaces  may  be  described  by  their  electrical,  mechanical, 
functional  or  procedural  characteristics.  Often,  interfaces  are  described  in  terms  of 
“form  and  fit”  (F^l),  or  “form,  fit  and  function”  (F^l). 

An  open  systems  approach  applies  wideiy  used  interface  standards  to  F^l  and  F^l 
interfaces.  An  interface  standard  is  a  standard  that  specifies  the  physical,  functional, 
or  military  operationai  environment  interface  characteristics  of  systems,  subsystems, 
equipment,  assemblies,  components,  items  or  parts  to  permit  interchangeability, 
interconnection,  compatibiiity  or  communications  (MIL-STD-962C). 

The  success  of  the  open  systems  approach  depends,  in  large  part,  on  how  well  system 
interfaces  are  defined  and  managed. 
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OPEN  SYSTEMS  DEFINITION 


Open  Systems  implement  common 
interfaces,  services,  and  supporting  formats 


OPEN  SYSTEM 

•  A  collection  of  interacting 
components  designed  to  satisfy 
stated  needs  with  the  interface 
specification  of  components 

•  fully  defined 

•  available  to  the  public 

•  maintained  according  to  group 
consensus 

•  In  which  the  interactions  of 
components  depend  on  the  interface 
specification  and  the 
implementations  of  components  are 
conformant  to  the  specification. 


An  Open  Systems  Approach  ... 

Is  an  integrated  technical  and 
business  strategy, 

^  Uses  modular  hardware  and  software 
design, 

^  Applies  commercial,  widely  used 
interface  standards, 

^  To  buy,  rather  than  build. 
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One  definition  adopted  by  DoD:  A  system  that  implements  sufficient  open 
specifications  for  interfaces,  services,  and  supporting  formats  to  enable  properly 
engineered  components  to  be  utilized  across  a  wide  range  of  systems  with  minimal 
changes,  to  interoperate  with  other  components,  and  to  interact  with  users  in  a  style 
which  facilitates  portability.  An  open  system  is  characterized  by  the  following: 

•  Well  defined,  widely  used  preferably  non-proprietary  interfaces/protocols,  and 

•  Use  of  standards  which  are  developed/adopted  by  industrially  recognized  standards 
bodies  or  the  commercial  market  place,  and 

•  Definition  of  all  aspects  of  system  interfaces  to  facilitate  new  or  additional  systems 
capabilities  for  a  wide  range  of  applications,  and 

•  Explicit  provision  for  expansion  or  upgrading  through  the  incorporation  of  additional 
or  higher  performance  elements  with  minimal  impact  on  the  system. 
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INTERFACE  COMPARISONS 


^EEI 


WIDELY 

USED 


Market 

Acceptance 


NARROWLY 

USED 


BRTRC  I 


PRIVATE 


Standards  Base 


PUBLIC 
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Two  important  “consensus”  criteria  by  which  to  measure  products  based  on  standards 
are  their  openness  in  terms  of  formal  acceptance,  measured  on  the  horizontal  axis  in 
the  figure  shown,  and  their  openness  in  terms  of  market  acceptance,  measured  on  the 
vertical  axis. 

Our  goal  is  to  avoid  the  closed  systems  that  are  narrowly  used,  in  the  lower  left  corner, 
and  use  products  that  have  both  wide  market  acceptance  and  formal  acceptance. 
Popular  proprietary  systems,  such  as  Microsoft  Windows  95,  are  an  example  of  de 
facto  standards  having  wide  market  acceptance  that  can  have  a  use  in  DoD. 

Another  important  measure  is  performance.  Does  the  particular  standard  allow  the 
system  to  meet  its  performance  requirement,  now  or  in  the  future?  Does  the  standard 
allow  the  system  to  meet  its  “growing”  performance  requirements? 


3/17/98 


Open  Systems  Concepts 


17 


By  comparison,  closed  systems  are  characterized  as  systems  having  closed  interfaces 
for  the  majority  of  their  system’s  interfaces.  We  will  define  closed  interfaces  as  being 
either  unique  or  proprietary  or  system-specific.  Closed  systems  are  usually  referred  to 
as  being  “stovepiped,”  where  the  same  closed  interfaces  are  usually  used  within  a 
particular  weapon  systems  domain  (e.g.,  avionics,  missiles,  ground  vehicles, 
submarines,  etc.) 

Also,  note  that  open  systems  may  not  have  all  open  interfaces.  There  may  be  instances 
within  an  “open  system”  where  interfaces  are  closed  or  are  “partially”  open.  Closed 
interfaces  are  used  when  there  are  no  suitable  open  interfaces  that  can  meet  the 
performance  requirements.  “Partially”  open  interfaces  are  interfaces  based  on  open 
standards  which  have  been  extended  or  modified  in  some  manner  to  meet  certain 
performance  requirements  and,  therefore,  have  limited  or  narrowed  their  original 
market  support. 

A  challenge  in  applying  an  open  systems  approach  is  to  find  widely  supported 
interfaces  that  also  satisfy  demanding  weapon  systems  performance  requirements 
which  are  often  dictated  by  the  severe  environmental  conditions  in  which  our  systems 
operate.  Another  challenge  is  to  consider  modulating  requirements  to  allow  the  use  of 
standards-based  interfaces.  This  may  require  meeting  less  than  100%  of  requirements 
or  re-allocating  requirements  to  other  components  within  the  system. 
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Implementations  involve  the  “how  to”  or  detailed  design  of  a  particular  component  or 
subsystem.  Current  acquisition  policy  is  for  DoD  to  describe  the  performance  of  the 
desired  system  (i.e.,  performance  specifications)  and  not  specify  “how  to”  build  it.  Open 
systems  interface  specifications  are  often  confused  as  being  “detailed”  or  “how  to” 
specifications  when  they  are  actually  “performance  specifications”  for  the  interface. 

Many  different  implementations  may  be  available  in  the  marketplace  that  meet  a 
particular  component’s  performance  requirements.  Take  care  to  ensure  that  the 
implementation  procured  conforms  to  the  (open)  interface  specification  for  the  system. 

Open  systems  components  conform  to  standard  interfaces,  even  though  the 
implementation  may  be  proprietary. 

An  important  aspect  of  open  systems  is  that  open  interface  standards  allow  industry  to 
use  innovative,  often  proprietary,  technical  solutions  internally  that  keep  their  products 
competitive.  Ideally,  this  drive  by  manufacturers  to  continually  differentiate  their  product 
in  the  marketplace  provides  DoD  with  continually  upgraded  products  from  multiple 
sources  of  supply. 
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TAILORING  OPEN  SYSTEMS 


Below  the 
ATOMIC  LEVEI^^ 


Producer  controls 
design,  interfaces 
and  impiementation 

No  further  interface 
or  functional 
definition  by  User 

Expect  no  repair  by 
User 
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Where  within  the  system  are  interface  standards  important  to  us? 

The  atomic  level  is  defined  as  the  level  at  which  you  intend  to  repair  your  system  (e.g., 
lowest  repairable  unit,  LRU).  Above  this  level,  the  government  controls  the  interface. 
Below  this  level,  there  is  no  organic  repair  and  the  details  of  the  implementation  and 
lower  level  interfaces  are  left  to  the  manufacturer. 

Choose  the  atomic  level  and  associated  standards  based  on: 

•  Anticipated  Life  Cycle  Cost  drivers 

•  The  impact  of  rapidly  changing  technology  on  system  components 

•  The  likelihood  of  components  evolving  or  growing  in  capability  over  the  life  of  the 
system 

•  Performance,  risk  &  business  considerations 
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ATOM  1C  LEVEL  ILLUSTRATION  cqi^n 

 -w  El-K 


Do  you  define 

Atomic  Level 
at  the  subassembly, 
or  on  the 

individual  components? 


Note  that  atomic 
level  is  not  static  -- 
can  change  over 
time 

|[^  2/28/98 


$35K  Throwaway,  1985 


;120K  fully  repairable,  1968 


:;lf  "fiS!:  x-i . 


Open  Systems  Concepts 


20 


Note  that  atomic  level  may  vary  throughout  the  system  and  may  change  over  time.  The 
atomic  level  should  reflect  the  system’s  plan  for  evolution  over  time.  Defining  the 
atomic  level  too  low  may  limit  efficient  technology  insertion,  while  defining  the  atomic 
level  too  high  may  lead  to  the  use  of  proprietary  interfaces  for  major  system 
components  resulting  in  limited  supplier  support. 

In  the  figure  shown,  we  can  see  the  impact  of  technology  advances  on  the  atomic  level. 
Where  DoD  once  repaired  circuit  cards  at  the  “chip”  level,  it  is  now  more  common  to 
repair  at  the  circuit  board  or  higher.  Advances  in  technology  (increases  in  system 
processing  power  and  communications  capacity)  are  allowing  systems  engineers  to 
build  systems  with  fewer  instances  where  system  resources  (e.g.,  processors  and 
communications  capacity)  are  dedicated  to  particular  applications  to  ensure  real-time, 
fault  tolerance  services  over  distributed,  fully  connected  systems.  Instead,  system 
resources  are  being  allocated  dynamically,  as  needed.  As  a  result,  system 
architectures  are  shifting  away  from  federated  systems  to  more  integrated  systems.  As 
a  result,  the  atomic  level  move  higher  away  from  lower  level  interfaces  tied  to 
application-specific  components 
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WHAT  ISA  REFERENCE  MODEL? 

 -  El-K 


Abstract  Framework  to  establish... 

•  Common  understanding 

•  Identification  of  issues 

•  Context  for  discussion 

<cro^> 

Represents  types  and  kinds  of 

•  functions 

•  interfaces,  and 

•  features 

to  be  addressed  by  the  type  of 
system. 

The  Reference  Model  js  rjoi  H 

a  Product  or  System  Description! 
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A  reference  model  provides  a  high  level,  generalized  system  view  of  the  weapon 
system  family.  A  reference  model  is  intentionally  generalized  and  does  not  imply  any 
specific  system  implementation.  Its  purpose  is  to  provide  a  common  conceptual 
framework,  and  define  a  common  vocabulary  so  that  diverse  components  within  the 
domain  can  better  coordinate  acquisition,  development  and  support  of  domain  systems. 
A  reference  model: 

Provides  a  framework  for  how  to  apply  standards.  Particularly,  how  to  identify  interfaces 
critical  to  achieving  system  technical  and  business  goals.  Reference  models  establish 
a  context  for  understanding  how  disparate  technologies  and  standards  relate  to  each 
other. 

Embodies  the  earliest  set  of  design  decisions.  The  reference  model  is  important 
because  it  is  a  common  high-level  communications  vehicle  for  system  stakeholders. 

Specifies  the  atomic  level.  The  reference  model  forms  the  organizational  plan  for 
development.  It  forms  the  basis  for  specification  of  the  repairable  (atomic)  level  of  the 
system  and  becomes  the  foundation  for  product  line  development.  Well-formed 
reference  models  exhibit  modularity.  A  reference  model  begins  the  breakout  of  the 
subsystems. 
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LAND  VEHICLE  REFERENCE  MODEL 

_  —  =l:k  _ 


A  Reference  Model  represents  several 
systems  having  similar  functions 
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As  an  abstract  description,  a  reference  model  can  apply  to  a  number  of  different 
systems.  It  is  not  a  specific  system.  Here  we  examine  a  land  vehicle  reference  model. 

The  reference  model  provides  a  framework  for  the  discussion  of  the  connectivity  of  the 
system  entities.  It  is  associated  with  a  domain  of  interest  (scope  of  functionality). 

In  some  cases,  DoD  workgroups  have  established  standard  reference  models.  For 
example,  there  is  a  technical  reference  model  for  information  technology  in  the  Joint 
Technical  Architecture,  based  on  a  commercial  model.  Joint  Technical  Architecture 
version  1 .0,  Aug  ’96.  Version  2.0  is  being  worked,  scheduled  for  Mar  ’98) 

Joint  Weapon  Systems  Technical  Architecture  Working  Group  (JWSTA  WG)  is  the 
group  who  chooses  weapons  domain  specific  standards  for  inclusion  in  Weapon 
Systems  annex.  All  other  IT  standards  chosen  in  CORE  standards.  Standards  are 
chosen  to  mitigate  risk.  Standards  are  scrubbed  with  each  interaction  of  the  document. 
The  standards  are  updated  on  a  regular  basis.  Need  to  be  able  to  specify  that 
contractor  must  stay  current  with  mandated  standards,  or  have  a  plan  for  migration  to 
new  standards  as  they  occur. 
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TYPES  OF  ARCHITECTURES 


/  C 

MilEK 


Users 

Define 


Industry 
Creates 

System^^^ 


The  Building  Blocks 
(Products,  Services, 

Tools,  Processes) 

Definition;  The  structure  of 
components,  their  interrelationships, 
and  the  principles  governing  their  design" 
and  evolution 


System 

Architecture 


The  Blueprint 
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The  Operational  Architecture  specifies  the  “user  requirements,”  i.e.,  three  bedrooms,  2 
baths,  a  one-car  garage.  The  Technical  Architecture  constrains  the  system’s  design 
during  the  systems  engineering  process-our  building  codes.  The  System  Architecture 
emerges  as  an  output  to  the  systems  engineering  process  and  is  constructed  to  satisfy 
Operational  Architecture  requirements  per  the  standards  defined  in  the  Technical 
Architecture. 

In  the  housing  industry,  for  example,  the  “technical  architecture”  is  the  set  of  building 
codes  to  which  houses  are  built.  The  list  of  standards  that  is  designated  for  DoD 
weapons  systems  use  essentially  forms  a  technical  architecture  that  DoD  program 
managers  use  in  developing  their  “system  architectures.”  Again,  in  the  housing  industry 
the  “system  architecture”  is  the  blueprint  for  the  house  that  is  to  be  built.  Just  as 
blueprints  must  conform  to  the  building  codes,  DoD  weapon  systems  system 
architectures  must  conform  to  the  list  of  standards  designated  for  their  use.  Continuing 
with  the  housing  industry  analogy,  much  as  the  operational  architecture  would  reflect 
the  image  of  a  house  that  the  home  owner  would  expect  to  view  when  choosing  what 
kind  of  house  to  buy,  the  weapon  system’s  operational  architecture  would  reflect 
satisfying  those  requirements  that  it  was  designed  to  meet. 
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OPEN  SYSTEMS  EDUCATION 


•  Educate  your  managers,  system  engineers,  procurement  specialists, 
developers,  users,... 


•  Open  systems  represent  a  new  vocabulary  and  different  perspectives  - 
-  another  paradigm  shift 


Corporate  Management 

•  Enabler  for  your  project/organization  to  cross  traditional  boundaries 

•  Corporate  management  with  business-related  decisions  needs  to  participate  in 
procurement  and  life-cycle  management  policy 

•  Buy,  grow,  or  affiliate  technology  and  open  systems  expertise 

Program  Management 

•  Procurement  priorities,  life  cycle  management,  system  profile  specification, 
conformance  testing,  and  system  migration  may  be  new 

•  Technical  Management 

•  Open  interface  profiling,  defining  conformance  testing  ,  evaluating  Commercial 
Item  openness,  interoperability  testing  are  different  from  developing  and  designing 
unique,  optimum  solutions. 
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Education  in  open  systems  is  critical.  It  is  critical  that  there  be  no  problem  separating 
the  marketing  “hype”  of  open  systems  from  the  realities  of  open  systems  at  all  levels  of 
management,  development,...  participation. 

It  is  difficult  to  effectively  manage  complex  technical  change  when  the  change  crosses 
traditional  organizational,  and  technical  boundaries.  The  determination  of  the 
appropriate  specific  interfaces  will  be  based  on  the  consensus  reached  by  different 
functionality,  crossing  traditional  organizational  boundaries. 

Education  allows  participants  to  understand  the  underlying  motivation,  and  basis,  and 
provides  participants  with  an  opportunity  to  make  needed  contributions.  Participants 
generally  know  their  systems  functions  and  configurations  better  than  anyone  and  will 
be  the  individuals  who  actually  make  the  changes  to  the  systems. 
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THE  OPEN  SYSTEMS 
JOINTTASK  FORCE 


•  Established  by  the  Office  of  the  Undersecretary  of  Defense 
for  Acquisition  and  Technology 

•  The  Open  Systems  Joint  Task  Force  (OS-JTF)  was  formed 
in  September  1994  to: 

-  "Sponsor  and  accelerate  the  adoption  of  open  systems 
in  weapons  systems  and  subsystems  electronics  to 
reduce  life-cycle  costs  and  facilitate  effective  weapon 
system  intra-  and  interoperability." 

•  OSJTF  Web  Site  has  more  information 
http://www.acq.osd.mil/osjtf/ 

•  e-mail:  osJtf@acq.osd.mil 

•  Phone:  (703)578-6141 

•  FAX:  (703)575-0534 
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D  iscu  ssi  o  n  / 

E X e r else  Tasks 


Open  Systems 
Con  cep  t  s 

cq  u  i  s  i  t  i  0  n 


BRTRC  Institute 


This  presentation  has  described  the  concepts  and  principles  applied  in  using  an  OSA.  Examples  of  particular  weapons  system 
programs  have  been  used  to  illustrate  the  application  of  open  systems  principles  to  achieve  cost,  schedule  and  performance  benefits 
by  promoting  multiple  sources  of  supply  and  technology  insertion. 

Exercise  -  Selecting  Standards 

Situation:  You  are  specifying  interfaces  on  a  modification  of  automated  test  equipment  for  the  Navy's  F/A  -18  E/F.  Although  this  is  a  new 
aircraft,  it  will  employ  existing  servicing  and  test  equipment  to  the  maximum  extent  practical. 

The  tester  you  are  working  on  now  is  used  with  F/A-18  C/D  models,  and  has  a  modular  design.  One  module  is  a  militarized  computer 
meeting  some  of  the  architectures  of  the  commercial  Personal  Computer.  It  currently  uses  486-based  processors  with  EPP  parallel  ports  and 
standard  serial  interfaces.  You  intend  to  employ  commercially  available  CD-ROM  portable  readers  to  upload  information  specific  to  the  E/F  model  into  these 
engine  testers. 


Task:  Review  the  interface  standard  information  below,  and  perform  comparative  analysis  to  show  advantages  and  disadvantages  in  terms  of  openness, 


performc 


Circle  the  name  of  the 
interface  standard  you  would 
specify 


Then  select  the  one  you  would  use  in  this  situation. 


Technical  Survey  for  External  Peripheral  Device  Interfaces: 


Name 

Openness 

Performance 

Market  Acceptance 

Remarks 

Standard  Parallel 

Port 

Based  on  the 
implementation  by  IBM 
in  1981  with  a 

Centronics  36  pin 
connector. 

Transfer  Rate:  40-300Kbps 

Limited  bi-directional  capability  -  status 
signals  only,  not  useful  for  reading  from 
external  devices 

No  longer  in  production, 
superseded  by  recent  interface 
standards. 

Parallel  interface  transfers  8 
bits  simultaneously 

Standard  Serial 

Port 

Based  on  the 
implementation  by  IBM 
in  1981. 

Transfer  Rate  up  to  1 15  Kbps; 

Single  device  per  connection 

Supports  bi-directional  communication 

Older  technology,  now 
superseded  by  more  recent 
ECP/EPP  standards 

Serial  interface  transfers  1 
bit  at  a  time 

Extended 

Capability  Port 
(ECP) 

Joint  Hewlett 

Packard/Microsoft 

specification 

Transfer  Rate  up  to  2,000  Kbps; 

Single  device  per  connection 

Full  rate  bi-directional  information  transfer 

Market  Acceptance:  In 
production  on  numerous 
systems  with  wide  variety  of 
vendors  and  customization 
available 

Used  primarily  by  new 
generation  of  printers  and 
scanners. 

Backward  compatible  with 
parallel  port  standard. 
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(continued) 


Name 

Openness 

Performance 

Market  Acceptance 

Remarks 

Enhanced  Parallel 
Port  (EPP),  an 

IEEE  version  of 

ECP  standard 

IEEE  1284  (1994) 
Standard  Signaling 
Method  for  a  Bi¬ 
directional  Parallel 
Peripheral  Interface  for 
Personal  Computers 

Transfer  Rate  up  to  2,000  Kbps; 

Single  device  per  connection 

Bi-directional  information  transfer 

Market  Acceptance:  In 
production  on  numerous 
systems  with  wide  variety  of 
vendors  and  customization 
available 

Used  primarily  by  non¬ 
printer  peripherals,  CD 

ROM,  tape,  hard  drive, 
network  adapters,  etc.. 
Backward  compatible  with 
parallel  port  standard 

Universal  Serial 

Bus  (USB) 

Universal  Serial  Bus 
Implementers  Forum 
(industry  group  with 
open  membership) 

Transfer  Rate  up  to  12,000  Kbps; 

Up  to  127  devices  per  connection; 

Bi-directional  information  transfer 

In  production  on  Compaq, 

Digital,  IBM,  NEC,  Sony,  Intel, 
Microsoft  and  others. 

Products  now  appearing: 
joysticks,  CD  changers,  digital 
cameras,  videophone  cameras, 
handheld  scanners,  mice. 

Not  backward  compatible 
with  earlier  serial  or  parallel 
interfaces. 

Projection  -  peripherals 
now  using  parallel  ports  will 
move  to  USB. 

Expect  to  replace  traditional 
serial  and  parallel  ports  in 
the  next  3  years. 

Apple 
"Fire  Wire" 

IEEE  1394(1995) 
Standard  for  a  High 
Performance  Serial  Bus 

Transfer  Rate  100-400  Mbps; 

Up  to  63  devices  per  connection 

In  development 

Capable  of  2  simultaneous 
video  channels  and  CD 
audio 

Originally  developed  by 
Apple,  now  an  IEEE 
Standard 

Supports  multi  speed  peripherals  and  bi¬ 
directional  information  transfer 

High  cost,  compared  to 
alternatives 
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Exercise  Solution  and  Discussion  Points 


Analysis: 

Standard  Parallel  Port  (SPP).  Old  technology  and  out  of  production.  Slow  transfer  rate  and  partial  backward 
compatibility  render  this  standard  an  unacceptable  solution. 

Standard  Serial  Port  (SSP).  Like  the  SPP,  the  SSP  is  an  old  standard  and  has  a  very  slow  transfer  rate.  Both  the  SPP 
and  SSP  have  below  average  market  acceptance  and  do  not  give  us  the  benefit  of  lots  of  suppliers. 

Extended  Capability  Port  (ECP).  A  proprietary/unique  standard  developed  by  Hewlett  Packard  and  Microsoft.  ECP  is 
backward  compatible  with  parallel  port  standard,  has  an  excellent  transfer  rate,  and  good  market  acceptance. 

Enhanced  Parallel  Port  (EPP).  A  fully  open  standard  approved  by  the  IEEE  standards  body.  Excellent  transfer  speed, 
good  market  acceptance  and  is  used  primarily  with  CD  ROMs.  Fully  backward  compatible. 

Universal  Serial  Bus.  Implementers  Forum  standard  is  less  open  than  IEEE  standard.  In  production  by  several 
suppliers.  Very  high  transfer  speed,  however  this  standard  is  not  backward  compatible. 

Apple  “Fire  Wire.”  An  open  standard  that  evolved  from  a  closed  or  proprietary  status  to  an  IEEE  open  standard.  Highest 
transfer  rate  of  all  choices.  Not  much  of  a  track  record  on  this  standard  thus  far  as  it  is  still  in  development.  Will  meet 
the  requirement  for  backward  compatibility,  however  does  present  a  certain  amount  of  risk  at  this  stage  in  development 
and  is  the  most  expensive  solution. 

Best  Choice: 

Enhanced  Parallel  Port  (EPP).  An  open  standard  which  meets  or  exceeds  performance  requirements  and  has  good 
market  acceptance. 
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